Дункан Эппинг опубликовал интересный пост, касающийся изменений в интерфейсе vSAN Data Protection, произошедших в новой версии пакета обновлений VMware vSphere 8 Update 3.
Впервые развернув vSphere/vSAN 8.0 U3, он сразу же начал искать интерфейс vSAN Data Protection. Он не смог его найти, но подумал, что это из-за использования какой-то странной альфа-версии продукта. Теперь, когда продукт вышел, эта функция должна быть доступна из коробки, верно?
Нет, не так. Вам нужно развернуть виртуальный модуль (Virtual Appliance), чтобы эта функция появилась в интерфейсе. Этот модуль можно найти в разделе «Drivers and Tools» в разделе загрузок vSphere Hypervisor, который находится по основными ссылками на дистрибутивы vSphere. Он называется «VMware vSAN Snapshot Service Appliance». Текущая версия называется «snapservice_appliance-8.0.3.0-24057802_OVF10.ova». Вам нужно развернуть этот OVA, при это настоятельно рекомендуется запросить для него DNS-имя и правильно зарегистрировать его. Автор возился с файлом hosts на VCSA и забыл добавить имя в локальный файл hosts на своем ноутбуке, из-за чего возникли странные проблемы.
Еще одна вещь, на которую стоит обратить внимание: документация предлагает загрузить сертификаты и скопировать текст для модуля. Это не то, что большинство из нас делает ежедневно. Вы можете просто открыть веб-браузер и использовать следующий URL «https://<имя вашего сервера vCenter>/certs/download.zip», чтобы загрузить сертификаты, а затем распаковать загруженный файл. Более подробную информацию можно найти здесь.
Внутри будут сертификаты, и если вы откроете сертификат в подходящем текстовом редакторе, вы сможете скопировать/вставить его в экран развертывания для OVA.
Теперь, когда вы развернули OVA и все правильно настроено, вы должны увидеть успешное выполнение задачи, а точнее две: загрузка плагина и развертывание плагина, как показано на следующем скриншоте.
Если вы получите сообщение об ошибке «error downloading plug-in», вероятно, это связано с одной из двух причин:
Файлы DNS / Hosts настроены некорректно, в результате чего URL недоступен. Убедитесь, что вы можете разрешить URL.
Отпечаток (thumbprint) сертификата был неправильно скопирован/вставлен. Здесь есть целый раздел по устранению этой проблемы.
Если у вас нет полноценного способа резервирования конфигураций серверов ESXi, но вы задумались о том, что будет если, то вот тут есть простой и свежий сценарий, который позволить вам сделать бэкап конфигурации и восстановить конфигурацию хостов ESXi.
Автор не хотел вручную создавать резервные копии каждого ESXi хоста, так как это не масштабируется. Вместо этого он создал PowerShell скрипт под названием vCenter ESXi Config Backup, который выполняет в автоматическом режиме.
Скрипт vCenter ESXi config backup подключается к VMware vCenter, далее использует его для подключения к каждому ESXi хосту и последовательно создает резервную копию каждой конфигурации. Поскольку скрипт использует vCenter, вам не нужно включать SSH на каких-либо ESXi хостах для выполнения резервного копирования.
По умолчанию, скрипт предполагает, что вы не подключены к vCenter, и запросит вас подключиться к vCenter. Вы можете изменить это поведение, если вы уже подключены к vCenter, установив опциональный параметр connected со значением Yes.
Скрипт проверяет, существует ли указанная вами папка для резервного копирования. Если папка не существует, скрипт создаст ее.
Затем скрипт получает все ESXi хосты в vCenter, подключается к каждому из них и создает резервную копию конфигурации. Скрипт сохраняет резервную копию в указанную вами папку.
После завершения резервного копирования скрипт переименовывает файл резервной копии, добавляя к имени хоста установленную версию ESXi, номер сборки и дату резервного копирования.
Для использования скрипта необходимо предоставить несколько параметров. Первый параметр — vcenter, за которым следует FQDN-имя вашего vCenter. Второй параметр — folder, за которым следует расположение, куда вы хотите сохранить резервные копии конфигурации ESXi.
Вот что сказал об этом Shankar Iyer, CEO компании Omnissa:
Теперь мы - независимая софтверная компания, обладающая уникальной комбинацией талантов, технологий и активов экосистемы, сосредоточенной исключительно на обеспечении трансформационных рабочих пространств для клиентов и партнеров по всему миру.
С поддержкой KKR мы теперь обладаем гибкостью, приверженностью и инвестициями, чтобы занять наше место в качестве ведущей софтверной компании, определяющей и возглавляющей этот рынок с емкостью в 26 миллиардов долларов.
Этот момент был результатом более чем двухлетней работы, и я горжусь тем, что нахожусь в окружении высококвалифицированной команды менеджеров, которые неустанно работали для реализации нашего общего видения.
Наши 4000 сотрудников будут связаны общей структурой владения, которая объединит нас всех в путешествии по переосмыслению нашей отрасли и будущего работы.
Этот момент стал возможным благодаря нашим клиентам и партнерам. Мы не принимаем вашу лояльность как должное. Наше существование обусловлено вашим глубоким доверием к нашим технологиям и вашим сильным желанием реализовать видение автономных рабочих пространств, управляемых ИИ. Мы намерены продолжать заслуживать ваше доверие, создавая огромную новую ценность на нашей платформе и упрощая совместную работу.
В конце этого месяца мы проведем Omnissa Live, первое из серии мероприятий, чтобы полностью изложить наше видение и стратегию как самостоятельной компании и исследовать захватывающие возможности, которые мы видим впереди. Пожалуйста, запланируйте присоединиться к нам там. Мы знаем, что последние семь месяцев вызвали неопределенность. Сегодня с уверенностью я могу заверить вас, что мы готовы привести вас к новым высотам.
Нашим технологическим коллегам – лидерам инноваций и пионерам в различных категориях, таких как операционные системы, облачные среды, системы безопасности, платформы приложений и устройства – мы с нетерпением ждем тесного сотрудничества с вами и создания экосистемы, наполненной гибкостью и выбором, для наших и ваших клиентов.
Напомним, что продуктовый портфель компании теперь выглядит так (это больше не-VMware продукты):
Выглядит это как-то так (только вместо vpxd написано vmidentity):
При этом некоторые пользователи могут откатиться (Rollback) к исходному дистрибутиву, а у кого-то этот селектор неактивен (загреен). При обращении в техподдержку VMware пользователям было сказано, что на эту тему готовится KB, а пока можно воспользоваться приведенным ниже воркэраундом.
Проблема связана с некорневым сертификатом с псевдонимом ssoserver. В VMware есть внутренний документ по этой проблеме, но он пока не доступен публично. Вот шаги, которые VMware предоставляет для исправления:
1. Подключитесь по SSH к серверу vCenter
2. Выведите список сертификатов и определите псевдоним некорневого (Non-CA) сертификата с CN=ssoserver
/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'
3. Сделайте резервную копию сертификата, который показывает CN=ssoserver
Примечание: замените <Alias> на идентификатор псевдонима, определенный на предыдущем шаге.
5. Повторно выведите список сертификатов и убедитесь, что сертификат удален
/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'
Теперь можно продолжить обновление vCenter.
Правда у некоторых пользователей после удаления сертификата возникает ошибка, и неясно, нужно ли вручную восстанавливать сертификат после наката обновления. Ждем разъяснений VMware на эту тему.
Вчера мы писали о новых возможностях последнего пакета обновлений VMware vSphere 8.0 Update 3, а сегодня расскажем что нового появилось в плане основных функций хранилищ (Core Storage).
Каждое обновление vSphere 8 добавляет множество возможностей для повышения масштабируемости, устойчивости и производительности. В vSphere 8 Update 3 продолжили улучшать и дорабатывать технологию vVols, добавляя новые функции.
Продолжая основной инженерный фокус на vVols и NVMe-oF, VMware также обеспечивает их поддержку в VMware Cloud Foundation. Некоторые функции включают дополнительную поддержку кластеризации MS WSFC на vVols и NVMe-oF, улучшения по возврату свободного пространства (Space Reclamation), а также оптимизации для VMFS и NFS.
Ключевые улучшения
Поддержка растянутых кластеров хранилищ (Stretched Clusters) для vVols
Новая спецификация vVols VASA 6
Кластеризация VMDK для NVMe/TCP
Ограничение максимального количества хостов, выполняющих Unmap
Поддержка NFS 4.1 Port Binding и nConnect
Дополнительная поддержка CNS/CSI для vSAN
vVols
Поддержка растянутого кластера хранилища vVols на SCSI
Растянутый кластер хранения vVols (vVols-SSC) был одной из самых запрашиваемых функций для vVols в течение многих лет, особенно в Европе. В vSphere 8 U3 добавлена поддержка растянутого хранилища vVols только на SCSI (FC или iSCSI). Первоначально Pure Storage, который был партнером по дизайну этой функции, будет поддерживать vVols-SSC, но многие из партнеров VMware по хранению также активно работают над добавлением данной поддержки.
Почему это заняло так много времени?
Одна из причин, почему реализация vVols-SSC заняла столько времени, заключается в дополнительных улучшениях, необходимых для защиты компонентов виртуальных машин (VMCP). Когда используется растянутое хранилище, необходимо наличие процесса для обработки событий хранения, таких как Permanent Device Loss (PDL) или All Paths Down (APD). VMCP — это функция высокой доступности (HA) vSphere, которая обнаруживает сбои хранения виртуальных машин и обеспечивает автоматическое восстановление затронутых виртуальных машин.
Сценарии отказа и восстановления
Контейнер/datastore vVols становится недоступным. Контейнер/datastore vVols становится недоступным, если либо все пути данных (к PE), либо все пути управления (доступ к VP, предоставляющим этот контейнер) становятся недоступными, либо если все пути VASA Provider, сообщающие о растянутом контейнере, отмечают его как UNAVAILABLE (новое состояние, которое VP может сообщить для растянутых контейнеров).
PE контейнера vVols может стать недоступным. Если PE для контейнера переходит в состояние PDL, то контейнер также переходит в состояние PDL. В этот момент VMCP будет отвечать за остановку виртуальных машин на затронутых хостах и их перезапуск на других хостах, где контейнер доступен.
Контейнер или PE vVols становится доступным снова или восстанавливается подключение к VP. Контейнер вернется в доступное состояние из состояния APD, как только хотя бы один VP и один PE станут доступны снова. Контейнер вернется в доступное состояние из состояния PDL только после того, как все виртуальные машины, использующие контейнеры, будут выключены, и все клиенты, имеющие открытые файловые дескрипторы к хранилищу данных vVols, закроют их.
Поведение растянутого контейнера/хранилища данных довольно похоже на VMFS, и выход из состояния PDL требует уничтожения PE, что может произойти только после освобождения всех vVols, связанных с PE. Точно так же, как VMFS (или устройство PSA) не может выйти из состояния PDL, пока все клиенты тома VMFS (или устройства PSA) не закроют свои дескрипторы.
Требования
Хранилище SCSI (FC или iSCSI)
Макс. время отклика между хостами vSphere — 11 мс
Макс. время отклика массива хранения — 11 мс
Выделенная пропускная способность сети vSphere vMotion — 250 Мбит/с
Один vCenter (vCenter HA не поддерживается с vVols)
Контроль ввода-вывода хранения не поддерживается на datastore с включенным vVol-SSC
Дополнительная поддержка UNMAP
Начиная с vSphere 8.0 U1, config-vvol теперь создается с 255 ГБ VMFS vVol вместо 4 ГБ. Это добавило необходимость в возврате свободного пространства в config-vvol. В 8.0 U3 VMware добавила поддержку как ручного (CLI), так и автоматического UNMAP для config-vvol для SCSI и NVMe.
Это гарантирует, что при записи и удалении данных в config-vvol обеспечивается оптимизация пространства для новых записей. Начиная с vSphere 8.0 U3, также поддерживается команда Unmap для хранилищ данных NVMe-oF, а поддержка UNMAP для томов SCSI была добавлена в предыдущем релизе.
Возврат пространства в хранилищах виртуальных томов vSphere описан тут.
Кликните на картинку, чтобы посмотреть анимацию:
Поддержка кластеризации приложений на NVMe-oF vVols
В vSphere 8.0 U3 VMware расширила поддержку общих дисков MS WSFC до NVMe/TCP и NVMe/FC на основе vVols. Также добавили поддержку виртуального NVMe (vNVME) контроллера для гостевых кластерных решений, таких как MS WSFC.
Эти функции были ограничены SCSI на vVols для MS WSFC, но Oracle RAC multi-writer поддерживал как SCSI, так и NVMe-oF. В vSphere 8.0 U3 расширили поддержку общих дисков MS WSFC до vVols на базе NVMe/TCP и NVMe/FC. Также была добавлена поддержка виртуального NVMe (vNVME) контроллера виртуальной машины в качестве фронтенда для кластерных решений, таких как MS WSFC. Обратите внимание, что контроллер vNVMe в качестве фронтенда для MS WSFC в настоящее время поддерживается только с NVMe в качестве бэкенда.
Обновление отчетности по аутентификации хостов для VASA Provider
Иногда при настройке Storage Provider для vVols некоторые хосты могут не пройти аутентификацию, и это может быть сложно диагностировать. В версии 8.0 U3 VMware добавила возможность для vCenter уведомлять пользователей о сбоях аутентификации конкретных хостов с VASA провайдером и предоставили механизм для повторной аутентификации хостов в интерфейсе vCenter. Это упрощает обнаружение и решение проблем аутентификации Storage Provider.
Гранулярность хостов Storage Provider для vVols
С выходом vSphere 8 U3 была добавлена дополнительная информация о хостах для Storage Provider vVols и сертификатах. Это предоставляет клиентам и службе поддержки дополнительные детали о vVols при устранении неполадок.
NVMe-oF
Поддержка NVMe резервирования для кластерного VMDK с NVMe/TCP
В vSphere 8.0 U3 была расширена поддержка гостевой кластеризации до NVMe/TCP (первоначально поддерживалась только NVMe/FC). Это предоставляет клиентам больше возможностей при использовании NVMe-oF и желании перенести приложения для гостевой кластеризации, такие как MS WSFC и Oracle RAC, на хранилища данных NVMe-oF.
Поддержка NVMe Cross Namespace Copy
В предыдущих версиях функция VAAI, аппаратно ускоренное копирование (XCOPY), поддерживалась для SCSI, но не для NVMe-oF. Это означало, что копирование между пространствами имен NVMe использовало ресурсы хоста для передачи данных. С выпуском vSphere 8.0 U3 теперь доступна функция Cross Namespace Copy для NVMe-oF для поддерживаемых массивов. Применение здесь такое же, как и для SCSI XCOPY между логическими единицами/пространствами имен. Передачи данных, такие как копирование/клонирование дисков или виртуальных машин, теперь могут работать значительно быстрее. Эта возможность переносит функции передачи данных на массив, что, в свою очередь, снижает нагрузку на хост.
Кликните на картинку, чтобы посмотреть анимацию:
VMFS
Сокращение времени на расширение EZT дисков на VMFS
В vSphere 8.0 U3 был реализован новый API для VMFS, чтобы ускорить расширение блоков на диске VMFS, пока диск используется. Этот API может работать до 10 раз быстрее, чем существующие методы, при использовании горячего расширения диска EZT на VMFS.
Виртуальные диски на VMFS имеют тип аллокации, который определяет, как резервируется основное хранилище: Thin (тонкое), Lazy Zeroed Thick (толстое с занулением по мере обращения) или Eager Zeroed Thick (толстое с предварительным занулением). EZT обычно выбирается на VMFS для повышения производительности во время выполнения, поскольку все блоки полностью выделяются и зануляются при создании диска. Если пользователь ранее выбрал тонкое выделение диска и хотел преобразовать его в EZT, этот процесс был медленным. Новый API позволяет значительно это ускорить.
Кликните на картинку для просмотра анимации:
Ограничение количества хостов vSphere, отправляющих UNMAP на VMFS datastore
В vSphere 8.0 U2 VMware добавила возможность ограничить скорость UNMAP до 10 МБ/с с 25 МБ/с. Это предназначено для клиентов с высоким уровнем изменений или массовыми отключениями питания, чтобы помочь уменьшить влияние возврата пространства на массив.
Кликните на картинку для просмотра анимации:
По умолчанию все хосты в кластере, до 128 хостов, могут отправлять UNMAP. В версии 8.0 U3 добавлен новый параметр для расширенного возврата пространства, называемый Reclaim Max Hosts. Этот параметр может быть установлен в значение от 1 до 128 и является настройкой для каждого хранилища данных. Чтобы изменить эту настройку, используйте ESXCLI. Алгоритм работает таким образом, что после установки нового значения количество хостов, отправляющих UNMAP одновременно, ограничивается этим числом. Например, если установить максимальное значение 10, в кластере из 50 хостов только 10 будут отправлять UNMAP на хранилище данных одновременно. Если другие хосты нуждаются в возврате пространства, то, как только один из 10 завершит операцию, слот освободится для следующего хоста.
Пример использования : esxcli storage vmfs reclaim config set -l <Datastore> -n <number_of_hosts>
Вот пример изменения максимального числа хостов, отправляющих UNMAP одновременно:
PSA
Поддержка уведомлений о производительности Fabric (FPIN, ошибки связи, перегрузка)
VMware добавила поддержку Fabric Performance Impact Notification (FPIN) в vSphere 8.0 U3. С помощью FPIN слой инфраструктуры vSphere теперь может обрабатывать уведомления от SAN-коммутаторов или целевых хранилищ о падении производительности каналов SAN, чтобы использовать исправные пути к устройствам хранения. Он может уведомлять хосты о перегрузке каналов и ошибках. FPIN — это отраслевой стандарт, который предоставляет средства для уведомления устройств о проблемах с соединением.
Вы можете использовать команду esxcli storage FPIN info set -e= <true/false>, чтобы активировать или деактивировать уведомления FPIN.
Кликните на картинку, чтобы посмотреть анимацию:
NFS
Привязка порта NFS v4.1 к vmk
Эта функция добавляет возможность байндинга соединения NFS v4.1 к определенному vmknic для обеспечения изоляции пути. При использовании многопутевой конфигурации можно задать несколько vmknic. Это обеспечивает изоляцию пути и помогает повысить безопасность, направляя трафик NFS через указанную подсеть/VLAN и гарантируя, что трафик NFS не использует сеть управления или другие vmknic. Поддержка NFS v3 была добавлена еще в vSphere 8.0 U1. В настоящее время эта функция поддерживается только с использованием интерфейса esxcli и может использоваться совместно с nConnect.
Начиная с версии 8.0 U3, добавлена поддержка nConnect для хранилищ данных NFS v4.1. nConnect предоставляет несколько соединений, используя один IP-адрес в сессии, таким образом расширяя функциональность агрегации сессий для этого IP. С этой функцией многопутевая конфигурация и nConnect могут сосуществовать. Клиенты могут настроить хранилища данных с несколькими IP-адресами для одного сервера, а также с несколькими соединениями с одним IP-адресом. В настоящее время максимальное количество соединений ограничено 8, значение по умолчанию — 1. Текущие версии реализаций vSphere NFSv4.1 создают одно соединение TCP/IP от каждого хоста к каждому хранилищу данных. Возможность добавления нескольких соединений на IP может значительно увеличить производительность.
При добавлении нового хранилища данных NFSv4.1, количество соединений можно указать во время монтирования, используя команду:
Общее количество соединений, используемых для всех смонтированных хранилищ данных NFSv4.1, ограничено 256.
Для существующего хранилища данных NFSv4.1, количество соединений можно увеличить или уменьшить во время выполнения, используя следующую команду:
esxcli storage nfs41 param set -v <volume-label> -c <number_of_connections>
Это не влияет на многопутевую конфигурацию. NFSv4.1 nConnect и многопутевые соединения могут сосуществовать. Количество соединений создается для каждого из многопутевых IP.
В настоящее время CNS поддерживает только 100 файловых томов. В vSphere 8.0 U3 этот лимит увеличен до 250 томов. Это поможет масштабированию для клиентов, которым требуется больше файловых хранилищ для постоянных томов (PVs) или постоянных запросов томов (PVCs) в Kubernetes (K8s).
Поддержка файловых томов в топологии HCI Mesh в одном vCenter
Добавлена поддержка файловых томов в топологии HCI Mesh в пределах одного vCenter.
Поддержка CNS на TKGs на растянутом кластере vSAN
Появилась поддержка растянутого кластера vSAN для TKGs для обеспечения высокой доступности.
Миграция PV между несвязанными datastore в одном VC
Возможность перемещать постоянный том (PV), как присоединённый, так и отсоединённый, с одного vSAN на другой vSAN, где нет общего хоста. Примером этого может быть перемещение рабочей нагрузки Kubernetes (K8s) из кластера vSAN OSA в кластер vSAN ESA.
Поддержка CNS на vSAN Max
Появилась поддержка развертывания CSI томов для vSAN Max при использовании vSphere Container Storage Plug-in.
Решение VMware Cloud Foundation Instance Recovery предоставляет собой руководство по восстановлению экземпляра VMware Cloud Foundation (VCF) с нуля до полностью работоспособной среды. Процесс включает подробные инструкции по восстановлению всего экземпляра VCF, включая управляющий домен и домены рабочей нагрузки VI, где необходимо восстановить все компоненты.
Руководство предлагает пошаговые инструкции для ручного восстановления вашего экземпляра VMware Cloud Foundation, а также комплексную автоматизацию в виде модуля PowerShell, чтобы ускорить и упростить процесс ручного восстановления, используя данные из инвентаря VCF SDDC Manager для реконструкции конфигураций. Это устраняет необходимость обращаться к документации, которая может быстро устареть в условиях постоянно меняющегося и сложного программно-определяемого центра обработки данных.
Сценарии использования
Примеры сценариев, когда вам может понадобиться этот процесс:
Полный сбой площадки
Восстановление после атаки вредоносного ПО или вымогателей (Ransomware)
Катастрофическая логическая порча данных
Это особенно важно для отраслей, которые должны соблюдать нормативные требования (такие как Акт о цифровой операционной устойчивости (DORA) в Европейском Союзе).
Немного о DORA
DORA — это регламент Европейского Союза (ЕС), вступивший в силу 16 января 2023 года, который создал обязательную, всеобъемлющую систему управления рисками информационных и коммуникационных технологий (ИКТ) для финансового сектора ЕС.
DORA устанавливает технические стандарты, которые финансовые учреждения и их критически важные поставщики технологий третьих сторон должны внедрить в свои ИКТ системы до 17 января 2025 года.
Организации также должны разработать планы обеспечения непрерывности бизнеса и восстановления после аварий для различных сценариев киберрисков, таких как сбои ИКТ-услуг, природные катастрофы и кибератаки. Эти планы должны включать меры по резервному копированию и восстановлению данных, а также процессы восстановления систем.
Хотя DORA является европейским регламентом, его действия распространяются на компании, работающие в ЕС, независимо от места нахождения их штаб-квартиры. Более того, DORA является примером регламента, который станет более распространенным в других юрисдикциях в ближайшие годы.
Восстановление экземпляра VCF — это не просто на бумаге
Регламенты возлагают на предприятия, такие как финансовые учреждения и связанные с ними поставщики технологий третьих сторон, серьезные обязательства по разработке надежных планов реагирования на сбои их систем.
Организации должны будут проводить периодическое тестирование своих планов, инструментов и систем, чтобы продемонстрировать способность восстанавливать критически важную инфраструктуру в случае сбоев в своевременной и повторяемой манере.
Краткое описание решения
Решение VMware Cloud Foundation Instance Recovery использует комбинацию процессов восстановления из бэкапов, восстановления работоспособности и ребилда данных для воссоздания экземпляра VCF с точно такой же конфигурацией, даже если было утрачено основное оборудование и центр обработки данных, в котором он находился.
Основные шаги
Перестройка/ребилд хостов VMware vSphere с использованием того же или нового оборудования на основе данных, извлеченных из резервной копии инвентаря VCF SDDC Manager
Выполнение частичного развертывания VCF
Восстановление экземпляров VMware vCenter и NSX Manager, а также SDDC Manager
Реконструкция кластеров vSphere, включая их сетевые конфигурации и настройки
Восстановление NSX Edges
Восстановление рабочих нагрузок (виртуальных машин)
Восстановление настроек рабочих нагрузок (группы DRS, теги vSphere и местоположения инвентаря)
Временная шкала восстановления VMware Cloud Foundation Instance Recovery
Чтобы минимизировать время общего восстановления в VMware Cloud Foundation, задачи восстановления могут выполняться в нескольких доменах рабочих нагрузок по перекрывающемуся графику, адаптированному под требования клиентов. Временная шкала предназначена для следующего примера конфигурации:
3 домена рабочих нагрузок VI
Домен VI 1 и домен VI 2 находятся в том же домене единого входа vCenter SSO, что и домен управления. Они находятся в режиме расширенной связи (Enhanced Link Mode, ELM).
Используется только версия VMware Cloud Foundation 5.x. Домен VI 3 находится в изолированном домене единого входа vCenter (SSO).
Шаблон восстановления для домена рабочих нагрузок VI в том же домене SSO можно расширить, если к домену управления vCenter подключены дополнительные домены рабочих нагрузок VI.
Автоматизация с помощью PowerShell
Автоматизация представлена в виде модуля PowerShell под названием VMware.CloudFoundation.InstanceRecovery, являющимся комплексным набором командлетов, который упрощает рутинные процессы и уменьшает вероятность ошибок в процессе реконструкции потенциально сложного и большого программно-определяемого центра обработки данных.
Это особенно полезно в случаях, когда задачи выполняются многократно, например, для каждого хоста ESXi или для каждой восстанавливаемой виртуальной машины.
Процесс полагается на способность извлекать данные из резервной копии менеджера SDDC, которую вы собираетесь восстановить. Это означает, что автоматизация может восстановить последнюю жизнеспособную резервную копию без необходимости полагаться на актуальность ручных процессов и документации.
Пример извлечения данных конфигурации из резервной копии менеджера SDDC для использования при восстановлении:
После извлечения каждый шаг процесса использует эти данные для контроля и автоматизации реконструкции.
В лабораторных условиях полные экземпляры VCF, включая домен управления и домены рабочих нагрузок VI, были восстановлены всего за два часа. Многие задачи для дополнительных доменов рабочих нагрузок можно выполнять параллельно или в пересекающемся режиме, чтобы минимизировать общее время восстановления экземпляра.
Это уже было протестировано в лабораторной среде одним из крупнейших клиентов VCF, и они очень рады тому, что это решение предлагает им в плане соблюдения нормативных требований.
У Broadcom есть планы по дальнейшему расширению автоматизации и процессов для поддержки дополнительных топологий, конфигураций и технологий, так что следите за обновлениями!
Известный блоггер Эрика Слуф опубликовал интересное видео, посвященное обеспечению высокой доступности и восстановлению после сбоя в кластере NSX-T Management Cluster.
В этом видео Эрик демонстрирует эти концепции в действии, рассматривая различные сценарии отказов и подробно обсуждая стратегии аварийного восстановления. Вы можете получить копию оригинального файла Excalidraw и презентационные слайды в форматах PDF и PowerPoint на GitHub.
Введение
Поддержание доступности кластера управления NSX-T критически важно для обеспечения стабильности и производительности вашей виртуализованной сетевой среды. Далее будут рассмотрены стратегии обеспечения высокой доступности (HA) управляющих компонентов NSX-T, а также описан процесс восстановления при сбоях и лучшие практики для аварийного восстановления.
Обзор кластера управления NSX-T
Кластер управления NSX-T обычно состоит из трех узлов. Такая конфигурация обеспечивает избыточность и отказоустойчивость. В случае отказа одного узла кластер сохраняет кворум, и нормальная работа продолжается. Однако отказ двух узлов может нарушить работу управления, требуя оперативных действий по восстановлению.
Высокая доступность в кластере управления NSX-T
1. Поддержание кворума
Для поддержания кворума кластер управления должен иметь как минимум два из трех узлов в рабочем состоянии. Это обеспечивает доступность интерфейса NSX Manager и связанных сервисов. Если один узел выходит из строя, оставшиеся два узла могут продолжать общение и управление средой, предотвращая простой.
2. Отказы узлов и их влияние
Отказ одного узла: кластер продолжает работать нормально с двумя узлами.
Отказ двух узлов: кластер теряет кворум, интерфейс NSX Manager становится недоступным. Управление через CLI и API также будет невозможно.
Стратегии восстановления
Когда большинство узлов выходит из строя, требуются оперативные действия для восстановления кластера до функционального состояния.
1. Развертывание нового управляющего узла
Разверните новый управляющий узел как четвертый член существующего кластера.
Используйте команду CLI detach node <node-uuid> или API-метод /api/v1/cluster/<node-uuid>?action=remove_node для удаления неисправного узла из кластера.
Эту команду следует выполнять с одного из здоровых узлов.
2. Деактивация кластера (по желанию)
Выполните команду deactivate cluster на активном узле для формирования кластера из одного узла.
Добавьте новые узлы для восстановления кластера до конфигурации из трех узлов.
Лучшие практики для аварийного восстановления
1. Регулярные резервные копии
Планируйте регулярные резервные копии конфигураций NSX Manager для быстрой восстановления.
Храните резервные копии в безопасном месте и обеспечьте их доступность в случае аварийного восстановления.
2. Географическая избыточность
Развертывайте NSX Manager на нескольких площадках для обеспечения географической избыточности.
В случае отказа одной площадки другая может взять на себя операции управления с минимальными перебоями.
Проактивный мониторинг
Используйте встроенные инструменты мониторинга NSX-T и интегрируйте их с решениями сторонних производителей для постоянного мониторинга состояния кластера управления.
Раннее обнаружение проблем может предотвратить серьезные сбои и уменьшить время простоя.
Площадка аварийного восстановления
Подготовьте площадку для аварийного восстановления с резервными NSX Manager, настроенными для восстановления из резервных копий.
Такая настройка позволяет быстро восстановить и обеспечить непрерывность работы в случае отказа основной площадки.
Заключение
Обеспечение высокой доступности и аварийного восстановления вашего кластера управления NSX-T необходимо для поддержания надежной и устойчивой виртуальной сетевой среды. Следуя лучшим практикам управления узлами, развертывания географически избыточной конфигурации и регулярного создания резервных копий, вы можете минимизировать время простоя и обеспечить быстрое восстановление после сбоев.
Для более детального изучения технических деталей ознакомьтесь с следующими ресурсами:
На сайте проекта Sample Exchange появилась утилита vKaan - vSphere Health Check - решение для управления виртуальной средой, предназначенное для поддержания конфигураций инсталляций VMware vSphere. Пакет vKaan позволяет отслеживать конфигурации Cluster HA и DRS и идентифицировать различающиеся объекты. Он также выявляет нарушения правил vSphere DRS и генерирует оповещения. Идентифицируя нарушения правил, он помогает обеспечить стабильность, эффективность и соответствие вашей среды vSphere желаемому состоянию.
Требования к системе Aria Operations
Для интеграции с пакетом управления версия vSphere API должна быть выше 8.0.1.0 (версии vSphere 7.x не поддерживаются).
Версия Aria Operations Manager должна быть выше 8.10.x.
Требования к правам пользователя Aria Operations Manager
Сервисная учетная запись для Aria Operations должна иметь разрешение только на чтение (read-only) с выбранной опцией распространения на дочерние объекты (Propagate to children) в vCenter Server.
Руководство по установке
Инструкции по установке и развертыванию:
Скачайте файл "vKaan - vSphere Health Check.zip" и извлеките его в папку.
Установите файл "vKaan - vSphere Health Check-1.x.x.x.pak" через меню Data Sources > Integration > Repository.
Это видео представляет собой углубленное обсуждение передовых методов управления емкостью в среде VMware Aria и Tanzu. Ведущие Brandon Gordon и Nico Guerra делятся опытом и знаниями о различных аспектах управления емкостью, начиная с определения ключевых терминов и понятий, таких как общая емкость, резерв под отказоустойчивость (HA), буфер, накладные расходы, использование, спрос и т.д. Особое внимание уделяется предсказательной аналитике, которая использует AI для анализа емкости и рекомендаций по оптимизации ресурсов.
Ключевые моменты видео включают:
Определение емкости - рассматриваются основные термины, такие как общая емкость кластера, резерв под отказоустойчивость, буфер, накладные расходы и фактическое использование ресурсов.
Модели управления емкостью - видео объясняет две основные модели – модель спроса и модель распределения, каждая из которых используется для оценки и планирования емкости.
Настройка прогнозов емкости - поясняются настройки уровня риска, концентрация на пиках нагрузки, консервативность и учет рабочих часов, что позволяет точно настроить прогнозы емкости для различных рабочих нагрузок.
Прогнозирование и рекомендации - видео детально рассматривает, как система прогнозирует оставшуюся емкость и рекомендует оптимальный размер ресурсов, исходя из текущих и будущих потребностей.
Всплески нагрузки - обсуждается, как система обрабатывает кратковременные, устойчивые и периодические пики нагрузки, чтобы точно учитывать их при прогнозировании емкости.
Интерфейс и использование - видео демонстрирует работу с вкладками и метриками в интерфейсе VMware Aria Operations, включая оценку оставшегося времени и виртуальных машин.
Видео предоставляет исчерпывающее руководство по использованию передовых методов управления емкостью в VMware Aria, что позволяет эффективно управлять ресурсами и планировать будущие потребности с учетом предсказательной аналитики и различных настроек системы.
VMware Tanzu — это огромная инновационная платформа, разработанная компанией VMware и принадлежащая сейчас Broadcom, предназначенная для управления современными приложениями в мультиоблачных средах. Tanzu предоставляет инструменты для разработки, развертывания и управления контейнеризированными приложениями с использованием Kubernetes. В этой статье мы рассмотрим ключевые аспекты экосистемы VMware Tanzu, и как она помогает организациям эффективно управлять своими приложениями.
Ключевыми компонентами VMware Tanzu являются следующие решения:
Tanzu Kubernetes Grid (TKG)
Tanzu Application Service (TAS)
Tanzu Mission Control (TMC)
Tanzu Observability
Tanzu Application Catalog (TAC)
Spring Boot
Многие продукты и технологии, которые вы знали ранее в продуктовом портфеле VMware (см. ниже о Wavefront или Cloud Foundry), были заведены под зонтик Tanzu (уже в составе Broadcom), который объединяет множество интересных направлений. Например, в состав экосистемы Tanzu входит решение Greenplum, которое представляет собой мощную и масштабируемую аналитическую базу данных с открытым исходным кодом, разработанную для выполнения сложных запросов и обработки больших объемов данных.
Кстати, посмотрите, как изменилась стоимость компании Broadcom, поглотившей VMware, с момента консолидации активов последней, в состав которых входят и решения Tanzu:
Основные компоненты VMware Tanzu
VMware Tanzu включает в себя несколько основных компонентов, которые вместе образуют мощную экосистему для управления приложениями:
1. Tanzu Kubernetes Grid (TKG)
TKG предоставляет готовое к использованию дистрибутив Kubernetes, который можно развернуть в различных средах, включая локальные дата-центры и публичные облака. TKG обеспечивает консистентность и масштабируемость, упрощая управление кластерами Kubernetes в различных окружениях.
Tanzu Kubernetes Grid является ключевым компонентом VMware Tanzu, предназначенным для упрощения развертывания и управления кластерами Kubernetes в мультиоблачных и локальных средах. TKG предлагает унифицированный подход к управлению Kubernetes, обеспечивая гибкость и консистентность, необходимые для современных приложений. Нижу мы рассмотрим основные возможности, архитектуру и преимущества TKG.
Основные возможности TKG:
Единый дистрибутив Kubernetes
TKG предоставляет готовый к использованию дистрибутив Kubernetes, который включает все необходимые компоненты для развертывания и управления кластерами. Это обеспечивает консистентность среды разработки и эксплуатации в различных окружениях.
Мультиоблачная поддержка
TKG поддерживает развертывание в различных облачных средах, включая AWS, Azure, Google Cloud, а также в локальных дата-центрах на базе vSphere. Это позволяет организациям выбирать наилучшее окружение для своих приложений.
Автоматизация управления кластерами
TKG автоматизирует многие аспекты управления кластерами Kubernetes, включая развертывание, обновление, масштабирование и мониторинг. Это сокращает трудозатраты и повышает эффективность операций.
Интеграция с экосистемой VMware
TKG интегрируется с другими продуктами VMware, такими как vSphere, vSAN и NSX, что обеспечивает высокую степень управления и безопасности для контейнеризированных приложений.
Поддержка современных рабочих нагрузок
TKG поддерживает развертывание и управление современными облачными приложениями, включая микросервисы и серверлесс-архитектуры, что позволяет организациям быстро адаптироваться к изменяющимся бизнес-требованиям.
Архитектура TKG:
Управляющий кластер
Management Cluster является основой инфраструктуры TKG. Он отвечает за управление всеми рабочими кластерами, включая их развертывание, обновление и масштабирование. Управляющий кластер также обеспечивает централизованное управление политиками и безопасностью.
Рабочие кластеры
Workload Clusters предназначены для развертывания приложений. Каждый рабочий кластер является полностью управляемым экземпляром Kubernetes, который может быть настроен и масштабирован в зависимости от потребностей приложения.
Tanzu CLI
Это командная строка, которая позволяет администраторам и разработчикам управлять кластерами Kubernetes и взаимодействовать с компонентами TKG. Tanzu CLI упрощает выполнение задач, таких как развертывание кластеров, обновление версий Kubernetes и управление политиками безопасности.
Расширения Tanzu Kubernetes Grid Extensions
TKG Extensions включают дополнительные компоненты и интеграции, которые расширяют возможности Kubernetes. Это включает мониторинг, журналирование, управление конфигурацией и сетевой политикой.
Преимущества использования TKG:
Упрощение управления Kubernetes
TKG значительно упрощает управление кластерами Kubernetes, предоставляя готовые к использованию инструменты и автоматизируя многие рутинные задачи. Это позволяет администраторам сосредоточиться на более стратегических задачах.
Гибкость и масштабируемость
С поддержкой мультиоблачных сред TKG обеспечивает высокую гибкость и масштабируемость, что позволяет организациям развертывать кластеры Kubernetes там, где это наиболее целесообразно с точки зрения производительности и затрат.
Повышенная безопасность
TKG интегрируется с инструментами безопасности VMware, такими как NSX, что обеспечивает высокую степень защиты для контейнеризированных приложений. Это включает сетевую сегментацию, контроль доступа и шифрование данных.
Быстрое развертывание приложений
TKG позволяет быстро развертывать и масштабировать приложения, что особенно важно в условиях динамически меняющихся бизнес-требований. Это обеспечивает конкурентное преимущество и ускоряет вывод новых продуктов на рынок.
Tanzu Kubernetes Grid (TKG) представляет собой мощное и гибкое решение для управления кластерами Kubernetes в мультиоблачных и локальных средах. Благодаря своим возможностям по автоматизации, интеграции с экосистемой VMware и поддержке современных рабочих нагрузок, TKG помогает организациям эффективно управлять своими приложениями и адаптироваться к изменяющимся бизнес-требованиям. В условиях быстро развивающегося ИТ-ландшафта TKG становится ключевым инструментом для успешного развертывания и эксплуатации облачных приложений.
После переезда ресурсов компании VMware на портал Broadcom было опубликовано несколько полезных материалов, касающихся решения для виртуализации и агрегации сетей виртуального датацентра VMware NSX. Основные из них мы приводим ниже: 1. NSX Certificate Management Cookbook...
В блоге Angry Admin появилась интересная статья, посвященная новому варианту основанного на Linux ПО, которое использует пакет TargetCompany Ransomware для атаки серверов VMware ESXi.
Важное событие в сфере кибербезопасности: исследователи Trend Micro выявили новый вариант Linux из печально известного семейства программ-вымогателей TargetCompany.
Этот вариант специально нацелен на среды VMware ESXi, используя сложный пользовательский shell-скрипт для доставки и выполнения вредоносных программ. Известный под несколькими псевдонимами, включая Mallox, FARGO и Tohnichi, ветка TargetCompany представляет собой постоянную угрозу с момента ее появления в июне 2021 года, в основном сосредотачиваясь на атаках на базы данных в Тайване, Южной Корее, Таиланде и Индии.
Эволюция вымогателя TargetCompany
Вымогатель TargetCompany первоначально привлек внимание своими агрессивными атаками на различные системы баз данных, такие как MySQL, Oracle и SQL Server. В феврале 2022 года антивирусная компания Avast сделала значительный прорыв, выпустив бесплатный инструмент для расшифровки, который мог противодействовать известным на тот момент вариантам вымогателя. Однако к сентябрю 2022 года группа вымогателей восстановила свои позиции, переключив внимание на уязвимые серверы Microsoft SQL и используя Telegram в качестве платформы для угроз жертвам утечками данных.
Новый Linux-вариант вымогателя: подробный обзор
Недавно компания Trend Micro сообщила о новом варианте вымогателя TargetCompany для Linux, что является заметным изменением в стратегии выбора целей вымогателя. Этот новый вариант убеждается в наличии административных привилегий перед началом своих вредоносных действий. Пользовательский скрипт используется для загрузки и выполнения вредоносного кода, который также способен извлекать данные на два отдельных сервера. Эта избыточность гарантирует, что данные остаются доступными, даже если один сервер столкнется с техническими проблемами или будет скомпрометирован.
После проникновения в целевую систему, вымогатель проверяет наличие среды VMware ESXi, выполняя команду uname и ища строчку "vmkernel". Затем создается файл "TargetInfo.txt", который отправляется на сервер управления и контроля (C2). Этот файл содержит важную информацию о жертве, такую как имя хоста, IP-адрес, сведения об операционной системе, зарегистрированные пользователи и их привилегии, уникальные идентификаторы и подробности о зашифрованных файлах и каталогах.
Скрытные операции и атрибуция
Операции вымогателя разработаны так, чтобы оставлять минимальные следы. После завершения своих задач, shell-скрипт удаляет полезную нагрузку с помощью команды ‘rm -f x’, эффективно уничтожая любые доказательства, которые могли бы помочь в расследованиях после инцидента. Аналитики Trend Micro приписали эти атаки актору по имени «vampire», который также был упомянут в отчете Sekoia в прошлом месяце. IP-адреса, связанные с доставкой полезной нагрузки и получением информации о жертве, были отслежены до интернет-провайдера в Китае, хотя этого недостаточно для точного определения происхождения атакующего.
Влияние и рекомендации
Исторически вымогатель TargetCompany в основном нацеливался на машины под управлением Windows. Появление варианта для Linux и акцент на средах VMware ESXi подчеркивают эволюционирующую тактику и расширяющийся вектор угроз этой заразы. В отчете Trend Micro подчеркивается важность надежных мер кибербезопасности для противодействия этой растущей угрозе. Основные рекомендации включают включение многофакторной аутентификации (MFA), регулярное резервное копирование (в том числе на immutable хранилища) и поддержание обновленными всех систем. Кроме того, исследователи предоставили список индикаторов компрометации, включая хэши для версии вымогателя для Linux, пользовательского shell-скрипта и образцы, связанные с актором «vampire».
Заключение
Появление нового варианта вымогателя TargetCompany для Linux подчеркивает неустанную эволюцию киберугроз и необходимость бдительных и проактивных мер кибербезопасности. Организации должны оставаться информированными и подготовленными к защите от этих сложных атак, обеспечивая реализацию комплексных мер безопасности для защиты своих систем и данных. По мере того, как угрозы вымогателей, такие как TargetCompany, продолжают развиваться, организациям и частным лицам необходимо предпринимать проактивные меры для защиты своих систем и данных. Вот несколько основных советов и рекомендаций для предотвращения атак вымогателей:
1. Включите многофакторную аутентификацию (MFA)
Внедрите MFA для всех учетных записей и систем. Это добавляет дополнительный уровень безопасности, затрудняя злоумышленникам несанкционированный доступ даже при компрометации паролей.
2. Отключите доступ по SSH
Отключите доступ по SSH на системах, где он не требуется. Это уменьшает поверхность атаки, предотвращая несанкционированный удаленный доступ.
3. Используйте режим блокировки (lockdown mode)
Включите режим блокировки на критически важных системах, таких как VMware ESXi, чтобы ограничить административные операции и дополнительно защитить среду от потенциальных угроз.
4. Регулярное резервное копирование
Регулярно выполняйте резервное копирование всех критически важных данных и храните резервные копии оффлайн или в безопасной облачной среде. Это гарантирует возможность восстановления данных в случае атаки вымогателя без уплаты выкупа.
5. Обновляйте системы
Убедитесь, что все программное обеспечение, включая операционные системы, приложения и антивирусные программы, регулярно обновляются для защиты от известных уязвимостей и эксплойтов.
6. Сегментация сети
Сегментируйте сети, чтобы ограничить распространение вымогателей. Изолируя критические системы и данные, вы можете сдержать инфекцию и предотвратить ее влияние на всю сеть.
7. Обучение сотрудников
Проводите регулярные тренинги по кибербезопасности для сотрудников, чтобы информировать их о опасностях вымогателей, фишинговых атак и безопасных практиках в интернете.
8. Внедрите сильные политики безопасности
Разработайте и соблюдайте надежные политики безопасности, включая использование сложных уникальных паролей, ограниченный контроль доступа и регулярные аудиты для обеспечения соблюдения требований.
9. Развертывание передовых решений безопасности
Используйте передовые решения безопасности, такие как обнаружение и реагирование на конечных точках (Endpoint Detection and Response, EDR), системы обнаружения вторжений (IDS) и системы предотвращения вторжений (IPS), чтобы обнаруживать и смягчать угрозы в режиме реального времени.
10. Мониторинг сетевого трафика
Постоянно контролируйте сетевой трафик на предмет необычной активности, которая может указывать на атаку вымогателя. Раннее обнаружение может помочь смягчить последствия атаки.
11. План реагирования на инциденты
Разработайте и регулярно обновляйте план реагирования на инциденты. Убедитесь, что все члены команды знают свои роли и обязанности в случае атаки вымогателя.
12. Ограничение привилегий пользователей
Ограничьте привилегии пользователей только теми, которые необходимы для выполнения их ролей. Ограничение административных привилегий может предотвратить распространение вымогателей по сети.
Следуя этим советам и оставаясь бдительными, организации могут значительно снизить риск стать жертвой атак вымогателей и защитить свои критически важные системы и данные.
Продолжаем рассказывать об обновлениях проверенных решений VMware Validated Solutions, которые произошли в мае этого года. Напомним, что о мартовских обновлениях мы рассказывали вот тут.
Инфраструктура Private AI Ready для VMware Cloud Foundation
Инфраструктура Private AI Ready, готовая к использованию в VMware Cloud Foundation, представляет собой хорошо спроектированное проверенное решение, предоставляющее предприятиям инфраструктуру с поддержкой AI и GPU для создания платформы AI для дата-сайентистов и инженеров по машинному обучению, использующую VMware Cloud Foundation в качестве базового слоя ПО.
Отчетность о состоянии и мониторинг для VMware Cloud Foundation
Проверенное решение для отчетности о состоянии и мониторинга для VMware Cloud Foundation теперь поддерживает узлы Dell VxRail как для консолидированных, так и для стандартных архитектур.
Private Cloud Automation для VMware Cloud Foundation
Проверенное решение для автоматизации частного облака для VMware Cloud Foundation теперь поддерживает VMware Aria Automation 8.16.2.
Защита сайтов и восстановление после аварий для VMware Cloud Foundation
Проверенное решение Site Protection and Disaster Recovery for VMware Cloud Foundation для VMware Cloud Foundation теперь поддерживает VMware Site Recovery Manager 9.0 и vSphere Replication 9.0.
Управление идентификацией и доступом для VMware Cloud Foundation
Проверенное решение для управления идентификацией и доступом для VMware Cloud Foundation теперь предоставляет процедуру для полной автоматизации с использованием нового меню проверенных решений, предоставленного модулем PowerShell для VMware Validated Solutions. См. Реализация управления идентификацией и доступом с использованием автоматизации PowerShell.
Модуль PowerShell, написанный для поддержки автоматизации многих процедур, связанных с реализацией проверенных решений VMware для VMware Cloud Foundation.
Модуль помогает снизить количество ошибок, обеспечивая согласованность и надежность, а также ускоряет время развертывания этих решений. Команды модуля упрощают и автоматизируют этапы развертывания и конфигурации с использованием API продуктов или инструментов командной строки.
Основные моменты нового релиза:
Добавлено Start-ValidatedSolutionsMenu вместе с подменю для облегчения и ускорения использования.
Добавлены функции для проверки предварительных условий для каждого проверенного решения.
Добавлены функции для генерации подписанных сертификатов от Microsoft Certificate Authority для VMware Aria Suite и Site Recovery Manager, устраняя необходимость в использовании CertGenVVS.
Добавлена поддержка настройки ролей в VMware Aria Suite Lifecycle.
VMware Avi Load Balancer является первым в отрасли программно-определяемым балансировщиком нагрузки (Load Balancer, LB) для гибридных облаков, который предлагает распределенную архитектуру с встроенной автоматизацией и глубокую видимость приложений. Инновационные решения Avi позволяют ИТ-командам предоставлять балансировку нагрузки с той же скоростью, что и приложения, обеспечивая эластичность (горизонтальное и вертикальное масштабирование) и единообразную модель эксплуатации в гибридных мультиоблачных средах, включая VMware Cloud Foundation (VCF), традиционные центры обработки данных, а также публичные облака для виртуализированных сред, окружений Kubernetes и физических рабочих нагрузок.
Avi Load Balancer реализует новые возможности по следующим направлениям:
1. Приложения для VCF Private Cloud
Avi является предпочтительным балансировщиком нагрузки благодаря своей модели plug-and-play для VCF, предоставляя следующие уникальные преимущества:
Быстрое развертывание балансировщика благодаря встроенным интеграциям с vSphere и NSX.
Автоматизированный рабочий процесс LB с Aria Operations (ранее vRealize Operations, vROPs).
Новое - самообслуживание LB через интеграцию с Aria Automation (ранее vRealize Automation, vRA).
Расширенная видимость приложений для администраторов VCF, что позволяет быстро решать проблемы, связанные с приложениями, до обращения к команде сетевых администраторов.
2. Приложения для Kubernetes
В качестве ingress-балансировщика программно-определяемая и эластичная архитектура Avi идеально подходит для распределенной и динамичной природы контейнерных рабочих нагрузок. Преимущества Avi:
Встроенная автоматизация с Avi Kubernetes Operator (AKO).
Новое - Gateway API – это следующее поколение Kubernetes ingress, значительно уменьшающее потребность в настройках через аннотации и определения пользовательских ресурсов (CRD), а также обеспечивающее защиту клиентов для Kubernetes и бессерверных рабочих нагрузок.
Встроенная безопасность ingress – включая Web Application Firewall (WAF) – для защиты контейнерных рабочих нагрузок.
Дополнительная лицензия на эти функции не требуется.
3. Мобильные и 5G приложения
Avi предоставляет гибкое и последовательное решение для балансировки нагрузки для широкого набора телекоммуникационных и мобильных сценариев использования.
Новое - нативная многопользовательская поддержка, теперь обеспечивающая в 3 раза большую многопользовательскую поддержку с VCF и Telco Cloud Platforms (TCP).
Новое - полная поддержка недавно выпущенного TCP 4.0.
Новое - дальнейшие улучшения программно-определяемого IPv6 балансировщика нагрузки (с разделенными слоями управления IPv6 и распределенными слоями данных) для локальных и облачных решений.
4. Инструмент конвертации старых LB в Avi
Для упрощения и ускорения развертывания Avi в существующих инфраструктурах, VMware представила инструмент конвертации Avi. Этот инструмент:
Обнаруживает старые LB.
Извлекает конфигурации.
Конвертирует конфигурации и пользовательские правила старых LB (например, iRules) в Avi.
Развертывает конфигурации на Avi.
Этот инструмент ускорит миграцию старых LB на Avi, в том числе выполняемую командой профессиональных услуг VMware.
Самообслуживание балансировки нагрузки для VCF Private Cloud
Avi Load Balancer является предпочтительным балансировщиком нагрузки для VCF, полностью интегрированным и поддерживаемым, с функциями plug-and-play. Avi предоставляет беспрецедентную видимость приложений, что помогает администратору VCF быстро выявлять и устранять причины проблем с производительностью приложений в течение нескольких минут.
Клиенты, которые хотят предоставить возможности самообслуживания командам DevOps, считают старые балансировщики нагрузки тяжелыми в эксплуатации, так как их развертывание занимает недели, требуя множества ручных шагов и создания нескольких тикетов.
Интеграция Avi с Aria Automation предлагает командам приложений доступ в форме самообслуживания к услугам балансировки нагрузки уровней L4-L7 (см. Включение балансировки нагрузки как услуги для частного облака на основе VCF). Это позволяет командам приложений и инфраструктуры немедленно развертывать балансировку нагрузки при предоставлении приложений, с минимальными знаниями технологий балансировки нагрузки и без необходимости создания ручных тикетов. Интеграция помогает клиентам снизить операционные затраты, упростить и автоматизировать развертывание и управление емкостью балансировки нагрузки. Смотрите это короткое демонстрационное видео, чтобы увидеть, как легко включить балансировку нагрузки как услугу с использованием Aria Automation.
Увеличение многопользовательской поддержки Avi Load Balancer примерно в 3 раза
Предприятия развертывают крупномасштабные приложения, которые требуют эластичной и надежной балансировки нагрузки. Несколько команд и арендаторов должны иметь доступ к инфраструктуре частного облака. Avi Load Balancer значительно улучшил производительность и масштабируемость, увеличив поддержку многопользовательского режима почти в 3 раза. Теперь клиенты могут управлять большим количеством Avi Service Engines (балансировщиков нагрузки) для каждого развернутого Avi Controller.
Каждый контроллер может поддерживать до 800 маршрутизаторов уровня Tier-1 для VMware NSX-T Cloud. Клиенты не только имеют меньшее количество контроллеров для управления, но и значительно снижают операционные расходы по сравнению с устаревшими балансировщиками нагрузки. В результате, та же команда может управлять большим количеством арендаторов, что повышает производительность. Провайдеры облачных услуг VMware, ранее известные как VMware Cloud Provider Program (VCPP), используют Avi Load Balancer для оптимизации облачных операций и повышения качества предоставляемых услуг. Подробнее см. в этом вебинаре Feature Friday на YouTube.
Avi для Ingress-балансировки нагрузки Kubernetes и бессерверных рабочих нагрузок
Контейнеры по своей природе являются эфемерными и эластичными, постоянно запускаются и останавливаются, что делает устаревшие аппаратные балансировщики нагрузки с традиционными архитектурами неактуальными для облачных и контейнерных сред. В условиях, когда все больше рабочих нагрузок в производственной среде развертываются на платформах Kubernetes, открытые решения становятся нецелесообразными для требований предприятий. Чтобы идти в ногу со скоростью развертывания приложений и предоставлять решения по балансировке нагрузки и ingress корпоративного уровня, Avi Load Balancer предлагает идеальную архитектуру для контейнерных рабочих нагрузок со встроенной безопасностью.
Avi предлагает интегрированные ingress-услуги, которые включают ingress-контроллер, балансировку нагрузки, глобальную балансировку нагрузки серверов в нескольких кластерах (GSLB), WAF и аналитику приложений на одной платформе. Для клиентов, которые развернули Avi для своих виртуализированных рабочих нагрузок, это простое расширение на Kubernetes с использованием того же пользовательского интерфейса, последовательных рабочих процессов и политик. Avi является независимым от контейнерных платформ и поддерживает VMware Tanzu, RedHat OpenShift, Tanzu Application Service (TAS, ранее Pivotal Cloud Foundry) и другие.
Avi Load Balancer вводит общую доступность (GA) поддержки Gateway API в выпуске AKO 1.12.1. Avi добавляет продвинутые функции маршрутизации уровня L7, включая поддержку безсерверного Kubernetes, модификацию заголовков, вставку cookie и ключевой набор функциональных возможностей HTTProute. Avi предлагает продвинутую маршрутизацию трафика, лучшую масштабируемость и мониторинг на основе каждого маршрута, без необходимости в CustomResourceDefinition (CRD) или аннотациях.
Расширение программно-определяемого подхода для мобильных и 5G-приложений
С поддержкой распределенного IPv6, обеспеченной уникальной программно-определяемой архитектурой Avi и поддержкой Telco Cloud Platform 4.0, VMware Avi Load Balancer продолжает предлагать широкий набор сценариев использования: от 4G рабочих нагрузок в ВМ и виртуальных сетевых функций (VNF) до 5G контейнерных рабочих нагрузок и контейнерных сетевых функций (CNF).
Крупный телекоммуникационный клиент VMware сначала развернул Avi в своей корпоративной сети в качестве пилотного проекта. Впечатленная его простотой использования и аналитикой приложений, команда сетевых администраторов представила Avi своей основной телекоммуникационной команде, которая решила расширить использование Avi в Telco Cloud Platform, обеспечивающую 5G сеть для рабочих нагрузок Kubernetes.
С операционной точки зрения это точно такая же платформа для обеих сред, что делает простым обучение персонала и совместную работу по решению проблем с приложениями, которые могут затрагивать несколько команд. Многопользовательская поддержка была ключевым требованием для телекоммуникационных сценариев, поэтому масштабируемость была значительно улучшена с выпуском новой версии. Также Avi предоставляет гранулярный доступ на основе правил (RBAC) для различных арендаторов и команд.
Инструмент конвертации старых балансировщиков нагрузки в Avi
Чтобы еще больше упростить миграцию с устаревших аппаратных балансировщиков нагрузки и ускорить переход на частное облако VCF, Avi Load Balancer объявляет о начальной доступности (Initial Availability) инструмента конвертации на базе UI, который берет старые правила политик, преобразует конфигурации в встроенные функции Avi, а также в Avi DataScript (скриптовый язык на базе Lua). Клиенты разрывают цепь старых балансировщиков нагрузки, переходя от сложных конфигураций для каждого устройства к простому управлению политиками из центральной панели управления.
Больше деталей о последней версии VMware Avi Load Balancer вы можете узнать по этим ссылкам:
Ресурсы VMware Digital Learning и MyLearn успешно перешли на новую платформу с 6 мая 2024 года. Теперь ИТ-специалисты могут управлять своими учебными активностями из единого централизованного места. В результате этой миграции создана прочная основа для будущих улучшений и упрощения пользовательского опыта управления обучением.
Все пользователи MyLearn должны создать аккаунт Broadcom перед первым доступом к Learning@Broadcom. На платформе будут регулярно появляться новые курсы, предоставляя ИТ-специалистам всеобъемлющий и актуальный каталог курсов по стеку VMware Cloud.
Доступ к новой платформе
Чтобы получить доступ к новой платформе, выполните следующее:
1. Посетите портал поддержки Broadcom.
2. Введите свои учетные данные в правом верхнем углу. Вы должны были получить инструкции по созданию аккаунта в отдельном письме. Если вы не получили инструкции, обратитесь к руководству "Как получить доступ к цифровому контенту VMware VCF" для помощи в создании профиля.
3. Через вкладку "My Dashboard" прокрутите вниз до "Learning@Broadcom", чтобы получить доступ к порталу.
Внесенные изменения в портал обучения
Что вам следует ожидать:
Изменения в обучении с инструктором - имейте в виду, что все не-VCF клиенты должны обращаться к одному из авторизованных партнеров VCF Authorized Education Partners в своем регионе для регистрации на курс с инструктором. Нажмите здесь, чтобы найти партнера по образованию рядом с вами. Все клиенты VCF будут регистрироваться через Learning@Broadcom, следуя вышеописанным шагам, находя курс и прокручивая вниз до доступных дат.
Текущие клиенты VCF – Learning@Broadcom предлагает функции для самостоятельной регистрации на предстоящие курсы. Чтобы начать, получите доступ к порталу, следуя вышеуказанным инструкциям. Рекомендуется самостоятельно исследовать платформу и искать значок "Events".
Доступ к содержимому курсов - получите доступ к вашей текущей подписке через вкладку "VMware Subscriptions" на новой платформе и перейдите к выбранному курсу.
После входа в систему пользователи могут искать конкретные темы по VMware и записываться на курсы, которые лучше всего соответствуют их потребностям, всего несколькими кликами. Такой подход позволяет специалистам быть в курсе последних достижений в стеке VMware Cloud.
Поддержка
В Broadcom понимают, что освоение новой платформы может потребовать времени. Чтобы облегчить переход, были внедрены ресурсы поддержки, которые вы можете использовать. В дальнейшем, для решения проблем с учетными данными или техническими трудностями в рамках платформы, есть два способа связаться с командой поддержки:
Создайте тикет на Broadcom Support Portal - войдите, как указано выше, и создайте заявку через "My Cases" в левом навигационном меню. Дополнительную документацию по навигации поддержки можно найти здесь.
Создайте заявку через форму Broadcom Support Form - для этого используйте эту ссылку.
Добавьте страницу VCF Learning Page в закладки для получения дополнительных ресурсов.
Администраторы часто ищут способ, как получить список всех снапшотов в окружении VMware vSphere, поскольку они засоряют хранилище и могут потенциально замедлить работу виртуальных машин, а также привести к их сбоям (здесь золотое правило - не использовать пользовательские снапшоты в качестве бэкапов).
Для этих целей можно использовать специализированные утилиты, такие как RVTools, а можно воспользоваться фреймворком PowerCLI. Там вы можете выполнить одну простую команду:
Интересный пост от John Nicholson о размещении сервера VMware vCenter в растянутом кластере vSAN Stretched Cluster. В идеальном мире у вас есть управляющий кластер, который содержит ваш сервер vCenter, а вы управляете каждым кластером из него. Но, к сожалению, в реальном мире всё сложнее:
Необходимо тоже как-то управлять управляющим кластером.
Иногда нужно, чтобы кластер был полностью автономным.
Можно ли запустить сервер vCenter на управляемом им кластере?
Надо сказать, что всегда полностью поддерживался запуск сервера vCenter на управляемом им кластере. Высокая доступность (HA) в этом случае всё равно будет работать. Если вам нужно более подробно изучить этот вопрос, этот короткий видеоролик ответит на ваш вопрос.
Итак, какой лучший совет при размещении vCenter?
Используйте ephemeral port groups для всех управляющих сетей. Это предотвратит проблемы chicken-egg с виртуальными распределенными коммутаторами (vDS), которые раздражают, но с которыми можно справиться.
Автор предпочитает использовать правила DRS типа "SHOULD", чтобы vCenter "как правило" находился на узле с наименьшим номером или IP-адресом в кластере. Это полезно в ситуации, когда vCenter работает с ошибками и службы управления не запускаются, так как это упрощает поиск узла, на котором он работает. Обязательно избегайте использования правил "MUST" для этого, так как это не позволит vCenter запуститься в другом месте в случае сбоя данного узла.
А как насчет распределенного кластера? Например, у вас есть отдельный хост для запуска сервера Witness, стоит ли размещать его там?
Вот такое делать не рекомендуется. Всегда предпочтительнее запускать сервер vCenter там, где он будет защищен с помощью высокой доступности (HA), и ему не потребуется выключение для обновления хоста. Растянутые кластеры vSAN всегда поддерживают операции active/active, и многие клиенты часто настраивают их так, чтобы большинство рабочих нагрузок выполнялись в предпочтительном датацентре (preferred site). Если вы используете эту конфигурацию, рекомендуется запускать сервер vCenter во вторичном (secondary) местоположении по нескольким причинам:
В случае сбоя основного сайта, вы не останетесь «операционно слепым», поскольку HA со стороны vCenter будет активирована и восстановит рабочие нагрузки. Это снизит любые операционные простои, которые могли бы произойти в течение нескольких минут, пока сервер vCenter запустится на резервном узле основного сайта.
Он будет действовать как указатель на состояние здоровья вторичного датацентра. В целом полезно иметь какую-то рабочую нагрузку на вторичном сайте, чтобы понимать, как будут работать эти хосты, даже если это будет относительно легкая нагрузка.
Heath Johnson из VMware представляет обзор решения VMware Cloud Foundation (VCF), которое включает в себя комплексное решение для частных облачных данных, объединяющее вычислительные мощности, хранилища и сетевые технологии. В основе решения лежат гипервизор ESXi и центр управления vCenter, образующие vSphere, интегрированные в VMware Cloud Foundation. Также в состав входят продукты для программно-определяемого хранения данных vSAN и программно-определяемых сетей NSX, которые позволяют создавать виртуальные частные облака.
Для управления операциями в облаке используется пакет продуктов vRealize, который обеспечивает мониторинг, автоматизацию и возможности самообслуживания для развертывания бизнес-приложений. Инициализация системы осуществляется через виртуальный модуль Cloud Builder, который автоматически развертывает ESXi, vCenter, vSAN и NSX, после чего управление и автоматизация переходят к SDDC Manager. Это устройство отвечает за дальнейшее добавление ресурсов и обновление системы, обеспечивая единообразие и упрощение управления инфраструктурой.
VMware Cloud Foundation предлагает эффективное решение для современных ИТ-задач, включая поддержку современных приложений через Kubernetes и AI, упрощая управление данными, приложениями и оборудованием в рамках частного облака на предприятии.
Таги: VMware, VCF, Cloud, vSphere, NSX, vSAN, Video
Блоггер Yahya Zahedi планирует написать интересную серию постов об утилитах для траблшутинга кластеров VMware vSAN. Сейчас самыми полезными для этих целей являются следующие средства:
vSAN Skyline Health
vSAN Cluster Level Monitoring
vSAN Host Monitoring
vSAN VM Monitoring
В этом посте мы приведем его рассказ о самом функциональном продукте - vSAN Skyline Health.
Skyline Health — это средство самостоятельной диагностики, предназначенное для обнаружения и устранения проблем в средах vSphere и vSAN. Важно отметить, что хотя эта утилита часто ассоциируется с vSAN, она также доступна и для vSphere. Таким образом, она не является эксклюзивной для vSAN, ее можно и нужно использовать для vSphere.
Сегодня мы посмотрим, как использовать Skyline Health для vSAN. Вы можете получить доступ к этому средству, перейдя к кластеру vSAN, затем выбрав вкладку "Monitor" и выбрав Skyline Health в разделе vSAN. Здесь, в разделе "Overview", вы найдете две карточки: "Cluster Health Score", которая работает на основе недавних файндингов по здоровью, и "Health Score Trend", которая показывает тренд оценки здоровья за последние 24 часа. Этот тренд можно настроить, указав конкретный временной промежуток.
В разделе файндингов по здоровью есть четыре категории: Unhealthy, Healthy, Info, Silenced, которые вы можете использовать для диагностики проблем, устранения неполадок и траблшутинга. Давайте начнем с первой категории файндингов.
Находки категории Unhealthy относятся к важным проблемам, которые требуют внимания. Например, в данном случае используется не сертифицированное VMware устройство хранения данных, и если вы посмотрите на зону воздействия этой проблемы, в описании вы увидите Compliance, что означает, что устройства хранения не соответствуют списку совместимости оборудования VMware HCL.
Как вы можете видеть, есть три опции:
Silence Alert - заглушает предупреждение и перемещает карточку в категорию Silenced.
Troubleshoot - показывает новую карточку с инструкциями по решению проблемы.
View History Details - отображает историю проблемы.
Нажмем на View History Details:
Будет показана новая карточка, предоставляющая историческую информацию об этой конкретной проблеме. Вы сможете увидеть, сколько раз она произошла и в какие дни.
Если вы нажмете на "Troubleshoot", появится новая карточка, предоставляющая информацию о проблеме и основной причине для облегчения ее решения. В разделе "Why is the issue occurring?" вы найдете детали о причинах. В разделе "How to troubleshoot and fix" вы узнаете дополнительные сведения, в данном случае - какие устройства испытывают проблемы совместимости оборудования, а также рекомендуемые действия для эффективного решения.
Вторая категория — Healthy, которая относится к файндингам без каких-либо проблем, следовательно, не требующим дополнительного внимания. Все функционирует гладко, что указывает зеленый статус. Наша основная цель — обеспечить, чтобы все файндинги попадали в эту категорию, оставляя другие категории пустыми.
Третья категория — Info, она относится к находкам, которые могут не влиять напрямую на состояние vSAN, но важны для повышения общего здоровья и эффективности кластера vSAN. Эта категория включает в себя некоторые передовые методы и рекомендации, направленные на оптимизацию производительности и стабильности кластера vSAN.
Четвертая категория — Silenced. Если вы заглушите любые файндинги из других категорий, они появятся здесь. Если у вас есть проблемы, которые вы активно решаете в течение длительного времени, или по какой-либо другой причине предпочитаете не отображать их в категории Unhealthy или других категориях, вы можете нажать на Silence Alert, чтобы переместить их в эту категорию.
В следующем посте автор рассмотрит утилиту vSAN Cluster Monitoring.
В видеоблоге, посвященном платформе VMware vSphere, появилось интересное видео о технологии DPU (data processing units). Напомним, что мы писали о ней вот тут и тут.
В данном подкасте "Vare break room chats", ведущий - Shobhit Bhutani, менеджер по продуктовому маркетингу в VMware, а гость - Motti Beck из NVIDIA, обсуждают вызовы, с которыми сталкиваются современные дата-центры, особенно в контексте сложности инфраструктуры. Основная проблема заключается в необходимости обработки больших объемов данных для задач машинного обучения, что требует параллельной обработки и высокопроизводительных сетевых решений.
Они говорят о роли технологий VMware и Nvidia в упрощении управления дата-центрами за счет использования решений на основе DPU, которые позволяют перенести часть задач с CPU на DPU, улучшая тем самым производительность и безопасность. Также обсуждаются достижения новой архитектуры данных, которая позволяет снизить задержки и увеличить пропускную способность, а также повысить энергоэффективность системы.
Примеры улучшений включают возможность работы с большим количеством правил безопасности и эффективное использование ресурсов, что подтверждается бенчмарками. Также поднимается тема удобства интеграции и управления такими системами - установка и настройка не отличаются от традиционных методов, что делает новую технологию доступной без дополнительных усилий со стороны ИТ-специалистов.
Многие администраторы часто добавляют новые хосты ESXi, но довольно редко обсуждается вопрос о том, как правильно выводить из эксплуатации хост VMware ESXi. Об этом интересную статью написал Stephen Wagner.
Многих может удивить, что нельзя просто выключить хост ESXi и удалить его из окружения сервера vCenter, так как необходимо выполнить ряд шагов заранее, чтобы обеспечить успешный вывод из эксплуатации (decomission). Правильное списание хоста ESXi предотвращает появление изолированных объектов в базе данных vCenter, которые иногда могут вызывать проблемы в будущем.
Итак, процесс: как списать хост ESXi
Предполагается, что вы уже перенесли все ваши виртуальные машины, шаблоны и файлы с хоста, и он не содержит данных, которые требуют резервного копирования или миграции. Если вы этого не сделали - проверьте все еще раз, на хосте могут оказаться, например, кастомные скрипты, которые вы не сохраняли в другом месте.
Вкратце процесс выглядит так:
Перевод ESXi в режим обслуживания (Maintenance Mode)
Удаление хоста из распределенного коммутатора vSphere Distributed Switch (vDS)
Отключение и размонтирование томов iSCSI LUN
Перемещение хоста из кластера в датацентр как отдельного хоста
Удаление хоста из инвентаря (Inventory)
Выполнение расширенных процедур
Вход в режим обслуживания
Мы переходим в режим обслуживания, чтобы убедиться, что на хосте не запущены виртуальные машины. Вы можете просто щелкнуть правой кнопкой мыши по хосту и войти в режим обслуживания (Enter Maintenance Mode):
Если хост ESXi входит в состав кластера VMware vSAN, то вам будут предложены опции того, что нужно сделать с данными на нем хранящимися:
Удаление хоста из окружения vSphere Distributed Switch (vDS)
Необходимо аккуратно удалить хост из любых распределенных коммутаторов vDS (VMware Distributed Switches) перед удалением хоста из сервера vCenter.
Вы можете создать стандартный vSwitch и мигрировать адаптеры vmk (VMware Kernel) с vDS на обычный vSwitch, чтобы поддерживать связь с сервером vCenter и другими сетями.
Обратите внимание, что если вы используете коммутаторы vDS для подключений iSCSI, необходимо заранее разработать план по этому поводу, либо размонтировать/отключить iSCSI LUN на vDS перед удалением хоста, либо аккуратно мигрировать адаптеры vmk на стандартный vSwitch, используя MPIO для предотвращения потери связи во время выполнения процесса.
Размонтирование и отключение iSCSI LUN
Теперь вы можете приступить к размонтированию и отключению iSCSI LUN с выбранного хоста ESXi:
Размонтируйте тома iSCSI LUN с хоста
Отключите эти iSCSI LUN
Нужно размонтировать LUN только на выводимом из эксплуатации хосте, а затем отключить LUN также только на списываемом хосте.
Перемещение хоста из кластера в датацентр как отдельного хоста
Хотя это может быть необязательным, это полезно, чтобы позволить службам кластера vSphere (HA/DRS) адаптироваться к удалению хоста, а также обработать реконфигурацию агента HA на хосте ESXi. Для этого вы можете просто переместить хост из кластера на уровень родительского дата-центра.
Удаление хоста из инвентаря
После перемещения хоста и прошествия некоторого времени, вы теперь можете приступить к его удалению из Inventory. Пока хост включен и все еще подключен к vCenter, щелкните правой кнопкой мыши по хосту и выберите «Remove from Inventory». Это позволит аккуратно удалить объекты из vCenter, а также удалить агент HA с хоста ESXi.
Повторное использование хоста
Начиная с этого момента, вы можете войти напрямую на хост ESXi с помощью локального пароля root и выключить хост. Сделать этого можно также с помощью обновленного VMware Host Client.
Недавно компания VMware выпустила интересное обзорное видео, посвященное решению VMware HCX, которое предназначено для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на базе VMware vCloud.
В этом видео эксперт VMware рассказывает о продукте VMware HCX в контексте сценариев для миграции рабочих нагрузок между различными облачными и локальными средами. Обсуждаются основные проблемы клиентов, связанные с миграцией данных и приложений, и какие решения предлагает VMware HCX для этих вызовов.
Рассматриваются ключевые возможности и версии HCX, включая мобильность рабочих нагрузок, оптимизацию WAN и гибридную связность. Также поднимаются вопросы управления ресурсами датацентров, проактивного избежания катастроф и управления затратами при миграции. Видео охватывает также стратегии выбора облака для специфических рабочих нагрузок и поддержку множественных облачных платформ. Это идеальный обзор для тех, кто хочет глубже понять возможности и преимущества использования VMware HCX в современных IT-инфраструктурах.
Некоторые пользователи, применяющие архитектуру VMware HCI Mesh для подключения емкостей удаленных кластеров в архитектуру VMware vSAN Express Storage Architecture (ESA) спрашивают - а можно ли таким образом подключить и емкости кластеров OSA (Original Storage Architecture)?
Напомним, что технология HCI Mesh появилась в VMware vSphere 7 Update 1, она позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов).
Мы уже касались этого вопроса здесь и указали на то, что это на данный момент не поддерживается. Дункан Эппинг вот тут рассказал о том, что это не только не сейчас поддерживается, но и невозможно.
Делов в том, что vSAN HCI Mesh (она же технология Datastore Sharing) использует проприетарный протокол vSAN, который называется Reliable Datagram Transport (RDT). При использовании vSAN OSA применяется другая версия протокола RDT, чем та, что используется в vSAN ESA, и в данный момент эти протоколы несовместимы. В итоге, нельзя использовать vSAN Datastore Sharing для предоставления емкости кластеров OSA в ESA или наоборот.
В будущем планируется исправить эту ситуацию, но в данный момент обходного пути нет.
Слишком большое количество оповещений и ложных срабатываний является одним из ключевых препятствий, мешающих организациям наладить эффективный мониторинг и противодействие угрозам в области информационной безопасности.
VMware Advanced Threat Prevention в составе решения VMware NSX предоставляет уникальную распределенную архитектуру, которая не требует перестройки сети, использования зеркалирования портов и ТАР (Traffic Access Point) или сенсоров для получения полной видимости горизонтального трафика. Решение дает полную видимость потока, а также контекст эндпоинтов, с использованием искусственного интеллекта и машинного обучения для обнаружения аномалий. Кроме того в VMware ATP есть система оценки и анализа корреляции для проведения аудита безопасности с набором согласованных и готовых к применению кампаний, позволяющих организациям сосредоточиться на угрозах, которые действительно влияют на их среду и игнорировать фоновый шум.
В этом демонстрационном видео рассматривается, как система безопасности VMware NSX (с встроенными функциями предотвращения продвинутых угроз и возможностями обнаружения и реагирования в сети) может обнаруживать и локализовывать сложные угрозы, использующие множество тактик и техник, применяемых в современных кампаниях по вымогательству и взлому.
Мы помним, что некоторые из вас просили рассказать о российских альтернативах платформам виртуализации от ведущих мировых вендоров. Оказывается, еще в 2022 году компании TAdviser и Softline подготовили подробное описание и сравнение российских платформ виртуализации по разным критериям, которое является хорошей отправной точкой для тех, кто больше не имеет возможности использовать продукты VMware.
Вот основные ссылки на информацию о российских производителях ПО для серверной виртуализации:
Обратите внимание, что данное исследование и сравнение сделано в декабре 2022 года, с тех пор многое могло измениться (в зависимости от активности разработчиков).
Полную версию этого отчета на 47 страницах можно скачать по этой ссылке (нужно заполнить форму внизу страницы):
Возможно вы не в курсе, что у компании VMware на YouTube есть отличный сборник воркшопов для самостоятельного изучения по большинству продуктов и технологий, которые были представлены на конференциях VMware Explore прошлых годов.
Сейчас этот плейлист насчитывает 35 видео, которые раскрывают аспекты практического использования (в том числе, в формате самостоятельных лабораторных работ - Hands-On Labs, HoL) не только основной платформы VMware vSphere, но и других важных продуктов, таких как VMware Aria, Site Recovery Manager, Tanzu, NSX и многих других.
Чтобы понять, что это такое, попробуйте посмотреть, например, вот этот ролик про расширенные возможности VMware vSphere 8, которые не так просто узнать из документации:
RSS
